- Start from some unique signals for your starting jumping point. Search and reduce your target files. - It's inefficient to read from top to bottom. Use commit history to target a smaller scope. - Write down what you read, even if that doesn't make sense at the moment. BFS instead of DFS. Build a priority queue to focus on things that matters. - The relationship to other part of the program. Run some snippet, isolate the code, use breakpoint, use logs. Get call stacks and understand the relations. - Link things you don't know to things you know, and follow things that you are able to understand in short period of time. This gives you more jumping points. - List things you need to understand, things you already know, and jumping points that are highly helpful. - Repeat keyword search and read if necessary.
This is an incredible talk. A lot of the things that are described here I've felt a strong need for clarity on in my programming. For those that stumble on to this, do not underestimate how essential these tips are. The feeling of overwhelm, discouragement, wasting time, etc. can feel brutal in a coding environment.
The first search result from googling "How to Read Unfamiliar Code by Josh Matthews" ---- www.joshmatthews.net/cusec16/unfamiliar.html so. everytime, I'd google before complaining it.
Here is a link to Aria Stewart talk about reading code: ruclips.net/video/-KgU5sxGtuM/видео.html I was also trying to find Lindsay Cooper blog post, but couldn't.
Cause an error and get call stack. Do it repeatedly till you get a good overview which can be recreated as a directed graph. This talk is a mess: just throw a lot of ideas at people and see what sticks, something should stick for everyone ;).
- Start from some unique signals for your starting jumping point. Search and reduce your target files.
- It's inefficient to read from top to bottom. Use commit history to target a smaller scope.
- Write down what you read, even if that doesn't make sense at the moment. BFS instead of DFS. Build a priority queue to focus on things that matters.
- The relationship to other part of the program. Run some snippet, isolate the code, use breakpoint, use logs. Get call stacks and understand the relations.
- Link things you don't know to things you know, and follow things that you are able to understand in short period of time. This gives you more jumping points.
- List things you need to understand, things you already know, and jumping points that are highly helpful.
- Repeat keyword search and read if necessary.
This is an incredible talk. A lot of the things that are described here I've felt a strong need for clarity on in my programming. For those that stumble on to this, do not underestimate how essential these tips are. The feeling of overwhelm, discouragement, wasting time, etc. can feel brutal in a coding environment.
Super talk, very professional and to-the-point while also being quite interesting. The enthusiasm is inspiring.
This is extremely helpful. Thank you
Thank you. very helpful.
next time film the presentation itself, not the presenter...
The first search result from googling "How to Read Unfamiliar Code by Josh Matthews" ----
www.joshmatthews.net/cusec16/unfamiliar.html
so. everytime, I'd google before complaining it.
nice video, it will be better if we can see the presenter screen.
can someone share the link for lindsay cooper and area steuart blogpost mentioned in the vides, I can not find it?
Here is a link to Aria Stewart talk about reading code: ruclips.net/video/-KgU5sxGtuM/видео.html
I was also trying to find Lindsay Cooper blog post, but couldn't.
Modern code is too complex for an average human to parse. Good talk on this titled (I think) "the mess we are in".
so it's basically a puzzle !
Thats a good analogy and i love game puzzles.
Ummmmmm no slides on a code reading video? Cmon….
Cause an error and get call stack. Do it repeatedly till you get a good overview which can be recreated as a directed graph. This talk is a mess: just throw a lot of ideas at people and see what sticks, something should stick for everyone ;).